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MESSAGE FORMS IN COMPUTER NETWORKS 


INTRODUCTION 


Network communication between computers is becoming increasingly 
important. However, the variety of installations working in the area 
probably precludes standardization of the content and form of inter- 
computer messages. There is some hope, however, that a standard way 
of defining and describing message forms can be developed and used to 
facilitate communication between computers. Just as ALGOL serves as 
a standard vehicle for describing numerous algorithms, and BNF serves 
as a standard for describing language syntax, a message description 
language would be useful as a standard vehicle for defining message 
formats. 

Considerable progress has been made at the low level of message 
handling protocol and one can expect the ASCII protocols to be used. 
The discussion which follows assumes that the mechanics of exchanging 
messages, check sums, repeat requests, etc., have been worked out. 
The topic of concern is how to describe the content and intent of a 
binary message body when the network header and trailer details have 
been stripped off. 

Most attempts at describing the content of binary messages 
jump immediately into a consideration of the bit codings to be used. 
Long, thin rectangles are drawn to represent the binary bit stream; 
this stream is sliced up into boxes, and tables generally describe 
the bit options for each box. A better approach would be to provide 
a symbolic method for describing messages. The symbolism, by 
avoiding immediate references to specific bit details, should help 
one’s understanding of the message content and the alternatives 
available in the message body. When the basic form of the binary 
message body is clear, the coding details of the actual bit fields 
can be shown. 
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Describing a binary message body is not much different from 
describing a text body or language. Text assumes fixed bit fields 
each containing one character. Standard language description methods 
(BNF) then show how the characters can be concatenated and what 
interpretation should be placed on character groups. Binary message 
descriptions require the additional capacity of defining various size 
fields in the message and the interpretation to be placed on the bits 
contained in the field. 

A message description is initially intended as a reference standard 
to be written down on paper and made available to new users of a 
computer network. From this standard, the new user can discover the 
kind and form of the binary data being exchanged over the network. 
Once this is known, the programs necessary for using the network 
facilities can be created. Later on, in an established network, one 
can envision the promulgation of standards for newly developed binary 
formats via the exchange of ASCII text messages over the network 
itself instead of on paper through the mail. Still farther into the 
future, the text of a binary format standard could be used as input 
to compiler-like programs which automatically create data translation 
programs for converting one binary format to another. Right now, 
though, some kind of binary data description method, however trivial, 
is desperately needed. 
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A SUGGESTED BINARY FORMAT DESCRIPTION METHOD 


The basic component of a binary message is a simple field 
consisting of a consecutive number of bits in the message. Binary 
messages consist of concatenated fields. A format description for a 
binary message will consist of a title and four declarative sections. 


1) Symbolic names are declared for all the different kinds of 
fields found in the binary format being defined. 

2) Symbolic names are declared for commonly used values of 
particular fields. 

3) The legal ways of concatenating fields are indicated. 

4) The number of bits in each field and any special considerations 
of bit codings are declared. 


The following is a complete example of a binary message description 
for a trivial kind of pictorial data. 


Title: Illustrative graphic data format for a hierarchally 
structured picture of lines and points. 
Simple Fields: 


OPT - Option Control Field 
COORD - Numerical Coordinate Value 
ID —- Identnumber for group of picture parts 


COUNT - Number of units in message 


Field Equivalents: 
PHDR <= '2' OPT 
LHDR <- TAT OPT 
GRPHDR <- ’1’ OPT 
GRPEND <- ’3’ OPT 
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+ GRPEND 


CPAIR <- COORD = 2 

POINT <- PHDR + CPAIR 

LINE <- LHDR + CPAIR = 2 

PARTS <- POINT/LINE/PARTS + PARTS 

PIXUNIT <- GRPHDR + ID + PARTS 

PIXMSG <- ’5’ OPT + N: COUNT + PIXUNIT = N + 
Simple Field Sizes: 

OPT 3 

COORD 14 

ID 9 

COUNT 6 


Declaration of Simple Fields 


The declaration of a simple field 
name, and for lack of a better way, 


the contents of the field represent. 


Simple Fields: 


F1 —- Geometric Options 
EXP - STD Number - Exponent 
COORD - STD Number - Geometric 


Representing Field Values 
A field with a specific value can 
single quotes followed by the field 
standard digits construed as binary 


includes a symbolic 
an English description of what 
For example: 


Coordinates 


be represented by a number in 
name. A number consists of 
if zeros and ones. Other numbers 


must be followed by a base indicator unless no confusion is possible; 


Q is octal, D is decimal. 
Example: 

11001” Fl 

1300D” COORD 

1271Q' EXP 


Field values are integer numbers assigned such that the least 


significant bit is sent first. 
fits the field is used. 


Only that part of the number which 
Appropriate sign extension is needed for 


negative numbers and for numbers whose bit representation is smaller 


than the field. 
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Simple Field Equivalents 
The declaration of a Simple Field Equivalent provides a symbolic 
name which represents a particular field with a specific value. 
Example: 
Field Equivalents: 
CT. <- '1001’ Fl 
C2 <= '1010’ FI 


Characterization Statement 

A characterization statement defines a complex field (message or 
message part) by indicating how other fields can be combined and is 
similar to a definition statement in BNF. The left side is a complex 
field name separated (by <-) from the concatenation indications on 
the right. Field names or equivalent names are concatenated by plus 
(+), alternatives indicated by slash (/). Slash has precedence over 
plus so that A + B/C means A followed by either B or C. Alternatives 
must be distinguishable in their own right. 

Characterization statement parts can be grouped in the normal 
manner by parentheses. (A + B)/C means either A followed by B or C. 


Repetition Indicators 
Repeated occurrences of a field may be indicated by following the 
field name with an equal sign (=) and a number. For example: 
CPAIR <- (COORD = 2) i.e. exactly two COORD fields 
PPAIRS <- (C1 + CPAIR = 10D) / (C2 + CPAIR = 40D) 


Assignments Within a Characterization Statement 
Simple fields interpretable as integers can be assigned to a 
variable within the right side of a characterization statement. This 
variable can then be used as a repetition indicator. Example: 


MS <- N1: EXP + CPAIR = N1 
indicates that MS consists of field EXP interpreted as an integer and 
then exactly that number of CPAIRS. All variables are global in 
scope. 


Conditional Fields 
Within a characterization statement a field may or may not 
occur depending on the contents of some other previous field. This 
situation is indicated by assigning a label to the determining field. 
The conditional occurrence is then indicated by enclosing a condition 
expression and the optional field description in brackets ([ and ]). 
For example: 
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SS <- V:F1 + CPAIR + [V = Cl > PPAIRS] 

which defines a format of 2 and perhaps 3 fields. 
a) Field Fl labeled V followed by 
b) Field CPAIR followed by 


c) Field PPAIRS if the first field (V) was Cl; otherwise, this 
third field is not present in the message. 


Conditional Alternatives 


Alternatives selected by the contents of some previous field rather 
than by the contents of the alternative field itself are indicated by 
an extension of the conditional field notation. For example: 

SM := W : F1 + CPAIR + [W = Cl > CPAIR / C2 > PPAIRS / 

The determining field occurs at the beginning of the conditional 
alternative and each alternative then includes its value for the 
determining field and the alternative field then present. 


Size of Simple Fields 


A separate field size declaration is provided. 
Simple Field Sizes: 


Fl 4 
EXP 7 
COORD 12 


This size declaration should appear at the end of the 
message description; thus, forcing the reader to postpone an early 
consideration of bit details. xmodmap -e "add lock = Caps_Lock" 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Dave Bachmann 1/98 ] 
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